with the pending db changes, an upgrade is ~as fast as a resync from genesis

In Bitcoin consensus, a txout index is stored as a uint32_t.
However, in practice, an output in a tx uses at least 10 bytes (for an OP_TRUE output), so
- to exhaust a 2 byte namespace, a tx would need to have a size of at least 2 ** 16 * 10 = 655 KB,
- to exhaust a 3 byte namespace, a tx would need to have a size of at least 2 ** 24 * 10 = 167 MB.

History.get_txnums and History.backup depend on ordering of tx_nums,
so we want the lexicographical order (used by leveldb comparator) to
match the numerical order.

For 1 million blocks, in a python dict, I guess this might take around 100 MB of RAM.
// - block_hash is 32 bytes, block_height is a varsize int
// - dict size seems to increase by 93 bytes for every new item
//   - however there is considerable additional overhead, I guess amortized over many adds,
//     for the hashmap. Looks like it takes around ~145 bytes per item overall.

squashed with:
- "blockchain.outpoint.subscribe" RPC: add optional "spk_hint" argument
- "blockchain.outpoint.subscribe" RPC: implement notifications
- "blockchain.outpoint.subscribe" RPC: distinguish heights "-1" and "0"
    Similar to scripthash statuses, the height of an unconfirmed tx is:
        - `-1` if it has any unconfirmed parents,
        - `0` otherwise.
- session: implement "blockchain.outpoint.get_status" RPC
- "blockchain.outpoint.subscribe": use bitcoind 31 gettxspendingprevout

txid_rev: txid in same endianness as prevouts are serialised in a raw tx
txid_hum: txid in endianness used for human-readable display typically
(these are reverses of each other)

e.g. to make it clear that these are methods that really need to do input sanitization

- also, in a recent commit I added prefixes to the db "state" keys:
  now add missing handling of old unprefixed keys to detect old DBs

postponing this from protocol 1.7 -- the motivation for adding this field was reliant on the "height" arg being optional, which we are also postponing.